home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SGI Varsity Update 1998 August
/
SGI Varsity Update 1998 August.iso
/
docs
/
relnotes
/
WorkShop
/
ch5.z
/
ch5
Wrap
Text File
|
1998-07-29
|
108KB
|
2,575 lines
- 1 -
5. _K_n_o_w_n__P_r_o_b_l_e_m_s__a_n_d__W_o_r_k_a_r_o_u_n_d_s
5.1 _W_o_r_k_S_h_o_p__D_e_b_u_g_g_e_r
+o F90 support: CVD does not provide sufficient support
for F90 specific constructs, such as array syntax,
dummy arguments, F90 pointers, and modules support.
Enhanced F90 support is a feature for the next release.
+o Fix and continue: Fix and continue is not supported
for applications that are compiled -n32.
+o 6.5 pthread problem: When doing process control, the
cvmain window's process control is really group, not
per thread.
+o 6.5 pthread problem: cvmain is a bit fair-weathered
about the thread it focuses on. That is, after doing
process control it can switch which thread is in focus.
The focused thread is not always the most interesting.
The intent is to allow 2 modes of operation. One which
follows the 'most interesting' thread. The other stays
focused on a particular thread until the user tells it
otherwise. Using the cvmp/cvmain together helps
figuring out the most interesting process.
+o 6.5 pthread problem: Not status-ing errored pthreads
correctly.
+o The Execution View is always raised when switching
processes or threads.
+o On the first print, cvd takes a very long time. Also
if a user uses the call stack view or does a "where" it
takes a very long time. For large applications the C++
expression evaluator sometimes requires excessive
amounts of resources to prepare for elaborate
evaluations. It does this despite the user potentially
only needing a basic expression evaluator. (PV 509646)
WORKAROUND : Use the following command in the commmand
window: "set $dbxCEval = true". This will cause cvd
to use the "dbx-like" expression evaluator instead of
the language specific one in the command window only.
The other views will still use the language specific
one.
To use the "dbx-like" expression evaluator in all the
views use -xrm "*dbxCEval" on the cvd command line or
set the resource in your .Xdefaults file and reload by
doing a "xrdb -load .Xdefaults".
- 2 -
Note: The "dbx-like" expression evaluator will not
allow you to print member variables without
dereferencing the "this" pointer explicitly. In the
future, the dbx-like expression evaluator will be
changed to understand the "this" ptr.
+o When stepping into a function call the program stops at
the beginning of the function prolog instead of at the
end where the parameters are available.
WORKAROUND : Do a next after stepping into a function
and the parameters will be updated.
+o Doing a "step into" when stopped on a line with a call
to "new" like the following, will result in stepping
into "operator new(<stripped>)". In dbx the user steps
into the constructor for "foo".
_foo = new foo ("foo");
WORKAROUND : Hit the "return" button and do another
"step into".
+o For some codes that use C++ templates users may get the
error when stopped in a C++ template function and
attempting to print member data : (PV 589766)
this = <syntax error>
Line <line>: error(3339): "this" may only be
used inside a nonstatic
member function
WORKAROUND : Use the following command in the commmand
window: "set $dbxCEval = true". This will cause cvd
to use the "dbx-like" expression evaluator instead of
the language specific one in the command window only.
The other views will still use the language specific
one. This is fixed in the 7.3 C++ compiler.
To use the "dbx-like" expression evaluator in all the
views use -xrm "*dbxCEval" on the cvd command line or
set the resource in your .Xdefaults file and reload by
doing a "xrdb -load .Xdefaults".
Note: The "dbx-like" expression evaluator will not
allow you to print member variables without
dereferencing the "this" pointer explicitly. In the
future, the dbx-like expression evaluator will be
changed to understand the "this" ptr.
- 3 -
+o Setting breakpoints in C++ template code that has been
implicitly included (see -auto_include on CC manpage)
and compiled -n32 is not supported. (PV 449121)
WORKAROUND : Users may attempt to recompile with
-no_auto_include.
+o Users of the -mp compiler option in 7.2 compilers could
see that cvd may catch a SIGTERM signal from the
libmp.so library during termination of the program. The
user will see that the process stopped in
_sginap(<stripped>). (PV 559781)
WORKAROUND : Users can set the environment variable
OMP_DYNAMIC to FALSE. This will cause the library to
perform similar to what it did in the 7.1 compilers as
it relates to termination.
+o Debugging of apps that use namespaces can lead to cvd
and dbx hanging, aborts and incorrect information being
generated.
+o Source files that share the same header file but reside
in different DSO's and are compiled with the -gslim
option are not supported. (PV 570369)
+o A program compiled with -n32 -g, unused variables can't
be clicked on
or printed in cvd. They could under -32 -g. (PV
596377)
+o The 2.6.5 version of the WorkShop debugger has problems
evaluating references to class data members and the
"this" pointer in C++ programs compiled with the 7.1
and 7.0 versions of the C++ compiler.
Workaround: You can recompile your code using the 7.2
or later version of the compiler. These expressions
work correctly with the output of the 7.2 or later
compiler. If you must debug 7.1 or 7.0 generated
programs or DSOs, use the following command in the
commmand window: "set $dbxCEval = true". This will
allow you to reference class data members, but you will
have to reference them as "this->member".
+o There is a limitation in the specification of the type
for a C++ exception trap. The determination as to
whether a particular type has been thrown does not take
into account typedefs. For example, given the type
definition:
- 4 -
ttttyyyyppppeeeeddddeeeeffff cccchhhhaaaarrrr ****SSSSttttrrrriiiinnnngggg;;;;
setting the breakpoint:
ssssttttoooopppp eeeexxxxcccceeeeppppttttiiiioooonnnn SSSSttttrrrriiiinnnngggg
would have no effect.
Workaround: Use the base type specified in the typedef
when setting the breakpoint.
+o After using cvd's Trap menu to change the setting of
Group Trap Default or Stop All Default, after an
extended period a dialog box may display the message
"Error: No debugger available to set trap modes". This
can be ignored.
+o Memory leak experiments might fail to unwind the stack
when particular functions are found in the stack (such
as usinit() from IRIX 6.2 libc or some libgl
functions).
+o The views that do expression evaluation, Expression
View, the Evaluate Expression dialog box, Structure
Browser, Variable Browser, Array Visualizer, and the
Debugger command line cannot yet evaluate:
- long double (C/C++) and unsigned variants
- real * 16 (Fortran) and unsigned variants
- complex *32 (Fortran) and unsigned variants
Evaluation of these types is not available at this
time. (Incident #206313)
+o Making an interactive function call when the target
process is sleeping in a system call will cause the
target to fault. (Incident #223601)
+o WorkShop does not accommodate text editors other than
Source View very well.
Workaround: Set the _e_d_i_t_o_r_C_o_m_m_a_n_d resource in the
_a_p_p-_d_e_f_a_u_l_t_s file to your desired editor. For example,
set _e_d_i_t_o_r_C_o_m_m_a_n_d to _w_s_h -_c _v_i +%_d to run _v_i in a _w_s_h
window. You also need to set *_u_s_e_T_o_o_l_T_a_l_k to _F_a_l_s_e.
+o The request to kill a process which has spawned child
processes (through _f_o_r_k(), _s_p_r_o_c(), or _s_p_r_o_c_s_p()),
followed by exiting _c_v_d, may not properly terminate the
- 5 -
descendant processes. The descendant processes may
continue to run after _c_v_d has exited. (Incident
#206273)
Workaround: Kill all of the process group members with
the Multiprocess View as opposed to using the Main
View. If any of the descendant processes were created
through a _f_o_r_k(), you will have had to direct the
Multiprocess View to attach to _f_o_r_k()ed process (see
``Config: Preferences'' in the Multiprocess View).
+o The Multiprocess View is known to occasionally not
display all process group members which _c_v_d is attached
to. One condition where this problem occurs is when
the list of processes shown by the Multiprocess View is
frequently changing in a short span of time (for
example, processes are _f_o_r_k()ed which _e_x_e_c() and exit
shortly after they start). (Incident #244782)
Workaround: Use of Stop in the Multiprocess View will
cause _c_v_d to stop all process group members and the
display should change to correctly list all processes.
+o When _c_v_d is brought up on one member of a running
shared process group (see _s_p_r_o_c(2)), _c_v_d does not
identify and attach to all of the other processes which
are members of the shared process group. If you start
up the Multiprocess View you will only see the process
you started _c_v_d on. The correct behavior from the
Multiprocess View would be to display all members of
the shared process group. (Incident #179940)
Workaround: Use ``Process: Add'' in the Multiprocess
View to manually add each member of the shared process
group to the _c_v_d process group display by Multiprocess
View.
+o Attempts to add a process which has been removed from
Multiprocess View may fail or lead to an abort of the
Multiprocess View. (Incident #168934)
+o Disassembly View sometimes has problems when two or
more DSOs have overlapping text. In such cases,
Disassembly View displays only one of the DSOs from the
set whose text overlaps. This can happen to users who
are building their own DSOs. Unfortunately _c_v_d does
not warn the user when this type of conflict occurs.
(Incident #204024)
+o On attempting to locate the DSOs used by an executable,
_c_v_d uses the shell environment in which _c_v_d was
- 6 -
started, as opposed to the shell environment within the
Execution View. This means that the value of
environment variables like LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH which are
used by _c_v_d may not match the values in the shell where
the executable will be run. When _c_v_d is using the
wrong values for environment variables like
LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH, it may have trouble finding all of the
appropriate DSO symbol tables. When _c_v_d has trouble
finding DSOs used by an executable it will display the
Library Search Path dialog to call attention to the
DSOs which could not be found. (Incidents #224125,
#236651)
Workaround: Use ``Admin: Library Search Path ...'' to
examine and set environment variables like
LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH which control the identification of
DSOs.
+o Watchpoints in _c_v_d may be defined with an address and
size or an expression. If you attempt to watch an
expression which resides on the stack (for example, a
local variable) _c_v_d will not allow definition of the
trap. _c_v_d will only watch expressions whose location
is within a mapping other than the stack. (Incident
#197233)
Workaround: If you want to watch an expression which
resides on the stack, use the expression evaluator to
find the address of the expression and create the
watchpoint using the address. Once the expression is
deallocated, the watchpoint should be removed to avoid
any confusion when the stack address is reused for some
other purpose later on in the execution.
+o Process group watchpoints involving expressions are not
supported well. If you create a watchpoint with a
command like ppppggggrrrrpppp wwwwaaaattttcccchhhh <<<<eeeexxxxpppprrrreeeessssssssiiiioooonnnn>>>>, the expression is
only evaluated once on one of the process group
members. The evaluation is used to determine the
address and size of the watchpoint, and address and
size is used to create a watchpoint on each process
group member. This will only work correctly if the
address and size of the expression is the same for each
process group member. There is no workaround known for
this problem. (Incident #143367)
+o The Trap Manager fails to properly define watchpoints
on 64-bit addresses. The address typed in the
``Trap:'' field is corrupted and either a watchpoint is
created on the wrong address or an invalid address
error is reported (_W_a_t_c_h_p_o_i_n_t _a_d_d_r_e_s_s _r_a_n_g_e _i_n_c_l_u_d_e_s _a_n
- 7 -
_i_n_v_a_l_i_d _v_i_r_t_u_a_l _a_d_d_r_e_s_s.). (Incident #235635)
Workaround: The command line interface panel in the _c_v_d
Main View can be used in place of the Trap Manager to
enter the watchpoint command.
+o A write watchpoint may fail to fire when the write
occurs within a syscall. For example, a write
watchpoint on one word within a buffer written by read
may fail to fire.
Workaround: Define the watchpoint to cover the entire
data structure as opposed to a subset of the structure.
For example, define the watchpoint over the entire
buffer being handed to read as opposed to a single
word.
+o An attempt to step into the first call to an external
function will behave like a step over. The first call
to an external function invokes rld to resolve the
function address. When this occurs the request to step
into the call will look like a step over to the user.
(Incident #147302)
Workaround: Either set the environment variable
_L_D__B_I_N_D__N_O_W to 1 in the Execution View prior to running
the program (see _r_l_d(1)) or use function entry
breakpoints.
+o Traps placed within a parallel Fortran DO loop, created
with the C$DOACROSS compiler directive, fail to work
correctly. Although the traps appear to be placed
correctly on 6.0 systems, the process will not stop on
the traps. (Incident #20818)
Workaround: On a 6.0 system _d_b_x can be used
successfully to place traps within the loop.
+o The Fortran intrinsics _c_h_a_r, _z_e_x_t, _s_e_c_o_n_d_s, _m_a_l_l_o_c, and
_e_p are not supported. (Incident #206293)
+o The debugger does not understand external or intrinsic
statements in the Fortran program. If the program has
a function by the same name as an intrinsic function,
evaluating an expression involving that function will
always cause the program function to be called.
+o Some of the intrinsics (_s_q_r_t, _e_x_p, _l_o_g, _l_o_g_1_0, _s_i_n,
_c_o_s, _t_a_n, _a_s_i_n, _a_c_o_s, _a_t_a_n, _s_i_n_h, _c_o_s_h, _t_a_n_h) do not
give the correct results when the debugged executable
is linked with _l_i_b_m._s_o. This is because of entry
- 8 -
points with similar names in _l_i_b_m._s_o.
Workaround: Use a specific intrinsic name. For
example, _s_i_n(_r_1) where _r_1 is real will produce
incorrect results. On the otherhand, _d_s_i_n(_d_f_l_o_a_t(_r_1))
will give correct results, with the results being a
_r_e_a_l *_8 quantity.
+o Stopping in the entry prologue of a function (before
the first user statement) in a Fortran program and
evaluating an expression that involves an adjustable
array or displaying an adjustable array in the Array
Visualizer will not work correctly. (Incident #206264)
Workaround: Step to the first user statement and
evaluate the expression.
+o When stopped in a Fortran function/subprogram that has
alternate entry points, the debugger will not list all
the arguments of the subprogram and their values
correctly. (Incident #164327)
+o For global lookups, _c_v_d acts as though all DSOs are
built ----BBBB ssssyyyymmmmbbbboooolllliiiicccc. If a process is stopped within a
DSO and the user asks _c_v_d to lookup a global variable
or function, _c_v_d will always look within the DSO before
it considers the main program or any other DSO. In
effect, _c_v_d is acting as if each DSO has been built
with ----BBBB ssssyyyymmmmbbbboooolllliiiicccc. (Incidents #173343)
+o Interactive calls to inline member functions of C++
classes is not supported.
+o The display format for describing an array pointer
types is incorrect. For example, an array of
double(*)[2] is expressed as double[]*.
+o Elements of Fortran arrays with more than 6 dimensions
(or 5 dimensions, if the element type is character
string) cannot be referenced.
+o C++ objects containing virtual base classes do not
display correctly in the expression evaluator.
(Incident #190170)
+o _c_v_p_c_s can stack trace through assembler alternate entry
functions only when they are at the same address as the
main entry point. Assembler functions with arbitrary
alternate entry points will produce incorrect stack
trace.
- 9 -
+o When the Trap Manager is invoked, traps are
automatically loaded from the ._c_v_T_r_a_p_M_g_r file if one
exists. However, these traps are reloaded if the Trap
Manager is closed and restarted. (Incident #79217)
Workaround: The Trap Manager should either be left
running or the default traps should be stored in a
different file and reloaded manually when desired.
+o In general, when a write watchpoint fires, the write is
simulated by the debugger to show the new value before
any trap conditional is evaluated. The four exceptions
for this case are the SC, SCD, SDL, and SDR
instructions. (Incident #250036)
+o A kernel bug prevents watchpoints from firing reliably
for members of share process groups (such as Power
Fortran or Power C programs). Watchpoints work
reliably for non-shared text and data segments in each
individual process.
+o If you stop a process through job control, the debugger
may not display an accurate status of the process, and
process control requests do not take effect until the
process is resumed through job control. A process is
stopped through job control with <Ctrl-Z> from the
shell or when it receives one of the signals: SIGSTOP,
SIGTSTP, SIGTTIN, and SIGTTOU. A process is resumed
through job control with _f_g and _b_g from the shell or
when it receives the signal SIGCONT. If a running
process is stopped through job control, the debugger
continues to show that the process is running. When
attaching to a process stopped through job control, the
debugger shows that the process is stopped. (Incident
#167693)
+o For instrumented executables (used for performance
analysis), stack frame unwinding may be incomplete when
stopped in a signal handler; the unwinding may stop
prematurely after the ``_sigtramp'' frame. (Incident
#71307)
Workaround: A full stack trace may be maintained by
returning past the ``_sigtramp'' frame.
+o The demo program _j_e_l_l_o cannot be built as described in
the tutorial without the library /_u_s_r/_l_i_b/_l_i_b_g_l._s_o.
Workaround: This library should be installed when IRIX
is installed (eoe1.sw.gfx_lib subsystem).
- 10 -
+o Processes that use the blocking capabilities as
provided by _b_l_o_c_k_p_r_o_c(2) may not terminate as expected
upon completion of a debug session. Such processes are
left in a blocked state with a SIGKILL pending.
Workaround: These processes can be terminated with
_k_i_l_l(1).
+o The modification of an inactive trap will cause the
trap to become active. You will have to toggle the
active button next to the trap description in order to
deactivate the trap. (Incident #190278)
+o There is a case where the path remapping component of
WorkShop will find the wrong file. When _c_v_d is stopped
and started multiple times, and ``Admin:Exit'' was used
to exit _c_v_d, the path remapping component will retain
entries in its Substitution Set from each debugging
session (see ``Admin:Project:Remap Paths...''). The
path remapping component of _c_v_d is implemented as a
separate process and the ``.'' entry in the
Substitution Set refers to the directory in which the
process was started, typically the directory were the
first _c_v_d was started.
Workaround: Use ``Admin:Project:Exit'' in place of
``Admin:Exit''. This will force the path remapping
process to terminate on each exit of _c_v_d.
+o By default the debugger will not attach to a _f_o_r_k()ed
process unless the fork occurs during an interactive
function call. If you have used the Multiprocess View
preferences dialog to prevent a forked child from being
resumed, and you make an interactive function call will
leads to a call on fork, the child process will be left
stopped on exit from fork. You must now use the
Multiprocess View to resume the child process.
(Incident #190308)
+o Fortran COMMON block members that are at an offset
greater than 8 Megabytes from the start of the common
block will not be evaluated correctly in an expression.
+o When using the Switch Process dialog to attach to an
existing process, don't attach to one of the CaseVision
or WorkShop processes (e.g. _c_v_p_a_t_h_R_e_m_a_p, _c_v_m_a_i_n) or the
environment may hang. Should this happen, kill the
_c_v_m_a_i_n process and start over.
+o Occasionally, _c_v_m_a_i_n will dump core at startup if you
have an executable with a mismatched core file and your
- 11 -
NetLS license is within 90 days of expiring. If this
happens, restart _c_v_d.
+o The main window's command line interface panel will
only display the first 100 elements of an array. There
is no way to change this behavior. (Incident #250028)
Workaround: The best way to examine an array is the
Array Browser.
+o The command line interface panel in the _c_v_d Main View
may fail to evaluate expressions when the process is
stopped and the language of the current context is
Assembler. (Incident #246294)
Workaround: The Expression View can be used in place of
the command line interface panel.
+o After a process has stopped, an expression value may
become invalid due to evaluation of another expression
or use of debugger commands which can lead to
modification of expression values. An example would be
the value of a variable displayed in Expression View
which is not recalculated after the variable is updated
with the _a_s_s_i_g_n command in the command line interface
panel. (Incident #247050)
Workaround: Force the value of the expression to be
recalculated by retyping the expression.
+o The Array Visualizer will no longer implicitly use _t_h_i_s
on a C++ program. When attempting to display the
member of a class you will have to explicitly include
_t_h_i_s-> along with the name of the member. (Incident
#248882)
+o Use of the division, and modulus operators in the
``Indexing Expression:'' field of the Array Visualizer
may not work correctly on 64-bit executables.
(Incident #249262)
+o _c_v_d may not list all the member functions of a class
correctly when the class and its member functions are
built into a separate DSO. (Incident #249733)
+o _c_v_d cannot evaluate expressions involving local classes
(classes that are defined inside of a function).
(Incident #212268)
+o The Query menu within _c_v_d will fail to operate
correctly if _c_v_d was attached to a running process (ccccvvvvdddd
- 12 -
----ppppiiiidddd ............) or if _c_v_s_t_a_t_i_c is started by hand (``Admin:
Launch Tool -> Static Analyzer''). (Incident #238595)
+o A trap at the closing brace of a C/C++ function may not
be defined properly. This is known to occur when the
last statement of the function is a return statement.
When this problem occurs the trap is defined on a
source line following the closing brace, typically the
opening brace of the next function.
Workaround: Place the trap on the source line
containing the return statement as opposed to the line
containing the closing brace. (Incident #277136)
+o _c_v_d may close file descriptors it should leave open in
the _r_u_n command. All file descriptors at 3 and above
are closed by _c_v_d. (Incident #277295)
+o The _c_v_p_c_s component of _c_v_d is known to occasionally
abort on erroneous expression evaluation requests from
the one-time expression evaluation component of _c_v_d.
(Incident #282160)
+o Evaluation of a C++ expression which contains a
variable whose name is the same as that of a structure
may lead to an erroneous error. (Incident #286949)
+o Under some conditions, on some R5K Indy and O2
machines, a hardware problem may cause traps to not
fire the first time they are encountered. Rerun often
works around the problem (Incident #439770).
5.1.1 _D_e_b_u_g_g_i_n_g__P_r_o_g_r_a_m__G_r_o_u_p_s__I_n_c_l_u_d_i_n_g__a__S_e_t_-_u_i_d__P_r_o_g_r_a_m
Because of standard IRIX security policies, the debugger can
not debug a program running as another user (unless you are
logged in as _r_o_o_t). This restriction applies even to system
programs which are set-UID, and even when all you want to do
with the set-UID program is debug something that it in turn
runs. It is common to use the system-provided set-UID
program _x_w_s_h (or _w_i_n_t_e_r_m, which in turn runs _x_w_s_h) in this
way.
There are two basic ways to deal with this problem. You can
become _r_o_o_t before starting your debugging session, which
grants you all necessary access rights (but may be
infeasible for your application or situation). Or, you can
arrange to use a non-set-UID copy of the intermediary
program, for example with _c_h_m_o_d, or by making a copy of the
program with _c_p.
- 13 -
There is also a bug in the IRIX 6.0 version of _x_w_s_h which
makes it unreliable if run non-set-UID. You may be able to
use _x_t_e_r_m instead of _x_w_s_h for these applications, for
example by using _w_i_n_t_e_r_m and setting the environment
variable WWWWIIIINNNNTTTTEEEERRRRMMMM to xxxxtttteeeerrrrmmmm before starting your debugging
session (and providing a non-set-UID copy of _x_t_e_r_m).
If your application depends on features of _x_w_s_h, can not use
_x_t_e_r_m instead, and can not be run as _r_o_o_t, then this
procedure will generally ensure that you can debug as non-
root:
+o Make a non-set-uid copy of _x_w_s_h (ccccpppp ////uuuussssrrrr////ssssbbbbiiiinnnn////xxxxwwwwsssshhhh ....).
+o Start several _x_w_s_h or _x_t_e_r_m windows, as the user who
will be doing the debugging. Exit them all. It is
important that they all be started together, all be
running at once, and then be exited immediately before
the debugging session begins.
+o Debug your application.
+o Set one or more breakpoints by function name ("stop in
main"), in the syscall panel, or with the ``Traps: Stop
at Function Entry'' menu - not by clicking in the glyph
bar of the main window. (Traps set on a particular
source line, as by clicking, are not copied from one
program to the next.)
+o Bring up the MPView, from the Admin menu.
+o Be sure all the "copy traps...." boxes are checked in
its configuration dialog.
+o Run your application, using MPView's ``Continue''
button as necessary and watching MPView for the
appearance of your subprocess. Double-click it to
launch a debugger on it.
5.2 _W_o_r_k_S_h_o_p__F_i_x_+_C_o_n_t_i_n_u_e
5.2.1 _L_i_m_i_t_a_t_i_o_n_s__o_f__F_i_x_+_C_o_n_t_i_n_u_e
+o You cannot add or delete global variables or functions.
+o You are restricted to editing the bodies of existing
non-inline functions. If you attempt to edit an inline
function, no warnings are emitted, but the results are
unpredictable.
- 14 -
Incident 240481
+o You cannot modify a function while the program is
sleeping in a system call, or is stopped on entry to a
system call. The debugger will detect this condition
and prevent you from loading the modified function
until you return from the system call.
You can set a trap on exit from the system call using
the System Call panel of cvd and continue the program
in order to get to a point where function loading is
allowed.
Incident 244664
+o The Multiprocess View capability of the debugger does
not interact well with the Fix and Continue feature.
sproc'ed and forked processes inherit the new
redefinition of the function. However, when starting a
debugger session on the new process, the debugger is
not aware that the process contains function
redefinitions. This means that there is no way to
deactivate the new definition in the new process after
a sproc() or a fork(). If the new function definition
is not desired in the new process, it is necessary to
stop the process on entry to fork() or sproc(),
deactivate the modified function and activate it again
on exit from fork() or sproc().
5.2.2 _K_n_o_w_n__P_r_o_b_l_e_m_s__w_i_t_h__F_i_x__a_n_d__C_o_n_t_i_n_u_e
+o The Disassembly View has not been updated to work with
the Fix and Continue feature. As a result, you will
notice the following behavior when viewing a modified
function in Disassembly View:
+o The filename displayed is incorrect, and reflects
the name of the temporary file used by the Fix and
Continue mechanism.
+o The assembly instructions are not interleaved with
the source code.
+o The line numbers shown in Disassembly View do not
reflect the line numbers used in the rest of the
debugger (i.e., instead of "7.3", the Disassembly
View will say line "9").
Incident 243635
- 15 -
+o The initialization value of local statics in C may not
be modified. If you make such a change, it will
silently be ignored. Since you are permitted to add new
local statics, you can accomplish a change of the
initialization value using the following workaround:
/* Original function */
void f() {
static int i = 0; /* oops. This should be -1 */
}
/* New function */
void f() {
static int i = 0; /* oops. This should be -1 */
static int first_time = 1;
if (first_time) {
i = -1;
first_time = 0;
}
}
Incident 246306
+o In C it is legal to call a function without declaring
it, and later declare the function to be static. For
example:
main(){
f();
return 0;
}
static int f(){
}
Since the Fix and Continue feature will only compile
"main", and since there is no declaration for "f", the
compiler will assume that "f" is an external function,
and there will subsequently by a "Load Error" in the
Interpreter Message window since the runtime loader
will be unable to find an external definition for "f".
The workaround is to make sure the compiler knows that
"f" is static when you use modify "main" during a Fix
and Continue operation:
main(){
static int f();
f();
return 0;
}
- 16 -
Incident 246317
+o When executing an older version of a function, you will
see the most recent source in the source window.
Consequently the line numbers, PC highlight, and
breakpoints displayed may be on the wrong lines.
+o If you open a source file using "Source:Open...", the
source file is opened in "Editable" mode by default.
This prevents Fix and Continue operations on the file,
and you will see the "Fix+Continue" button grayed out.
If you wish to use Fix and Continue on this file, use
the "Source:Make Read Only" menu option. If you use
"Source:Open..." to open a source file in which you
have previously modified functions, the modified
functions will not be highlighted while the source file
is editable.
If you save a file in which some changes were made
using Fix and Continue, and some changes were made
using "Source:Open...", confusion may occur. You can
workaround this by using "Source:Make Editable"
followed by "Source:Make Read Only". Another workaround
is to switch to some other file and then switch back to
the current file. Switching back can be accomplished by
making the process stop in the file or by using
"Source:Open..." followed by "Source:Make Read Only".
Incidents 243627, 243629, 248842
+o If you are stopped in a program, and you modify a
function which is not the one you are stopped in, after
the "Parse And Load" completes your source is
repositioned at the line on which you are stopped,
rather than at the function you just modified.
Incident 246739
+o The Fix and Continue mechanism does not currently check
to make sure that a file has not been modified after it
was last compiled. If you modify a function using Fix
and Continue, save the source back to its original
file, and forget to rebuild your application after
exiting the debugger, you will see unpredictable result
if you re-enter the debugger and attempt to use Fix and
Continue. For example, the debugger may think that
function "f" is on lines 15 to 20, whereas your
previous changes may have repositioned the function on
lines 17 to 22. When you select "Fix+Continue:Edit" if
you notice that the edit region does not cover the
entire body of the function, you should exit the
- 17 -
debugger and rebuild your application.
Incident 245098
+o If your original build compiled multiple files with a
single command line, this same command line will be run
when using Fix and Continue to modify a function in any
of those files, causing unnecessary recompilations of
the other files, and possibly erroneous results. For
best results, compile files one at a time using the -c
option of the compiler. If this is not possible, use
the Build Environment view to modify the command line
and remove all file names from it (Fix and Continue
will add in the file actually being compiled
automatically).
+o When you use the "Fix and Continue->Edit" menu item,
the region you are allowed to edit begins with the line
containing the first "{" of your function. This line
would include the line containing the function and
parameter declaration, for the coding style shown
below:
void f(int y){
/* .... */
}
In such cases, you should make sure you do not change
the function name and parameter profile. The
implementation does not currently check that you do not
make such changes, but you may receive a message like
this:
No reply from PCS;
unknown error while loading dso for the modified function
Incident 245299
+o If a "stop exit" trap is placed in a function, and Fix
and Continue is used on the function after hitting the
exit trap, then if execution can continue in the new
function, the PC is moved back to the beginning of the
line (it is in the epilogue, at the "jr ra"
instruction). This means the epilogue is re-executed.
This could cause problems if the stack pointer has
already been decremented, because now it will get
decremented twice. Your program may occasionally work
if the stack decrement happens to be after the "jr ra"
instruction. The implementation currently does not
always detect this condition.
- 18 -
The workaround is to reposition the PC at the "jr ra"
using PC->JumpTo after your F&C has completed.
F&C and templates
+o Using F&C on functions which use templates are not
completely supported in this release. Typically, if the
change involves instantiating new functions, then such
a change is not supported in this release. If the
process is stopped when this change is made, the F&C
error message window will display the error message
from rld under the PCS error messages. Otherwise, views
would temporarily show that the change is ok, but when
the process is run later , load error message will be
reported and the change is switched back to edited
state.
The error message would be something like: :
26095:/tmp_mnt/hosts/xanadu/usr/people/pal/kim/mnm:
rld: Fatal Error: unresolvable symbol in
/var/tmp/cvintp26042/cvfn1.3.so:
static_allocator__15vector__pt__2_i
Incident 249309
5.3 _W_o_r_k_S_h_o_p__M_o_t_i_f__A_n_a_l_y_z_e_r
+o If you create traps in the Motif Analyzer window using
the Breakpoints examiner, trap items will appear in the
Trap Manager window of the WorkShop Debugger. These
items will be labeled "MotifBreak." You should not
attempt to modify or delete these traps using the Trap
Manager. Instead, always use the Breakpoints examiner
to modify or delete your Motif-related breakpoints.
+o If you install the MegaDev.sw.motif subsystem and then
reinstall the WorkShop.sw.cvd subsystem, the "Motif
Analyzer" item will disappear from the Views menu in
the WorkShop Debugger. Reinstalling the
MegaDev.sw.motif subsystem will correct the problem.
+o If you install the WorkShop.sw.cvd and MegaDev.sw.motif
subsystems, and then remove only the MegaDev.sw.motif
subsystem, the "Motif Analyzer" menu item will still
exist in the Views menu in the WorkShop Debugger.
Selecting this menu item, however, will result in an
error dialog. Reinstalling the WorkShop.sw.cvd
subsystem will remove the item from the Views menu.
- 19 -
+o Occasionally, the Motif Analyzer display will remain
inactive after switching between processes using
WorkShop's "Switch Process" or "Switch Executable" menu
items, or when rerunning the process after changing the
command arguments. If this happens, close the Motif
Analyzer window and use WorkShop's Views menu to bring
it up again.
+o If your application connects to a remote X display and
you do not set LD_LIBRARY_PATH to include
/usr/lib/WorkShop/Motif, any Editres-type operations
(e.g. widget select and widget tree) will operate on
the local display and not work correctly. Either run
your program using the local X display or change
LD_LIBRARY_PATH as advised.
+o A small number of applications build their widget
hierarchy in such a way that Editres widget selection
operations cause them to exit with an X error. If your
application falls into this category, then using the
Motif Analyzer widget select functionality will cause
the same thing to happen.
5.4 _W_o_r_k_S_h_o_p__B_u_i_l_d__A_n_a_l_y_z_e_r
If target or dependency names are specified using
parentheses to denote files stored within an archive
library, _c_v_b_u_i_l_d will use a single node to represent the
archive library, rather than individual nodes for each file
within it.
5.5 _W_o_r_k_S_h_o_p__S_t_a_t_i_c__A_n_a_l_y_z_e_r
5.5.1 _G_e_n_e_r_a_l__K_n_o_w_n__P_r_o_b_l_e_m_s
+o The Directory Query "List Files" works only when the
query target is a full path name of a directory. For
example, it works on the target "/usr/include", but not
on a target like "include".
Workaround: Select the General Option "Full Pathnames".
Then any directory names displayed will contain full
paths, and so the "List Files" query will cork on them
correctly.
+o If you use _c_v_s_t_a_t_i_c to analyze a fileset and then
change one or more of the header files included by the
files in the fileset, rescanning the fileset will not
detect the change. Rescanning only detects changes to
- 20 -
source files listed in the fileset. Similarly, if you
remove a source file from a fileset and rescan, the
header files included by that file are not removed from
the database. (Incident #179731)
Workaround: If you have changed one or more files in a
fileset (or included by files in a fileset), you can
get a consistent database by selecting ``Force Scan''
from the Admin menu.
+o Some printers may clip the output when printing a
PostScript version of graph saved by _c_v_s_t_a_t_i_c.
Workaround: None, except trying another printer, or
re-laying out the graph by hand to avoid clipping.
5.5.2 _K_n_o_w_n__P_r_o_b_l_e_m_s__w_i_t_h__M_i_x_e_d__L_a_n_g_u_a_g_e_s
+o If you analyze a program that contains both Fortran and
C routines, _c_v_s_t_a_t_i_c in scanner mode does not recognize
that the C function ffffoooooooo____ and the Fortran function ffffoooooooo
refer to the same routine. In parser mode, _c_v_s_t_a_t_i_c
will identify the routines correctly, if it analyzes
the C file containing ffffoooooooo____ before the Fortran file that
calls ffffoooooooo. So, make sure that your C files appear
earlier in the fileset than your Fortran files.
- 21 -
5.5.3 _G_e_n_e_r_a_l__K_n_o_w_n__P_r_o_b_l_e_m_s__i_n__S_c_a_n_n_e_r__M_o_d_e
+o In general, _c_v_s_t_a_t_i_c does not require code to be able
to be compiled. _c_v_s_t_a_t_i_c should provide useful
information even when code has syntax errors. However,
there are several requirements that must be met for
_c_v_s_t_a_t_i_c to work properly. In C and C++, _c_v_s_t_a_t_i_c
relies on the existence of matching braces to determine
the beginning and ending of blocks and bodies of
functions. In Fortran, _c_v_s_t_a_t_i_c relies on the existence
of matching end statements. Functions without closing
braces, or end statements, or code with too many end
statements or mismatched braces can cause unpredictable
results. In C, it may be necessary to use _c_v_s_t_a_t_i_c's
----pppprrrreeeepppprrrroooocccceeeessssssss option with heavily _i_f_d_e_f'd code to achieve
matched braces.
If any of these limitations of scanner mode keeps
_c_v_s_t_a_t_i_c from being useful, using parser mode may be
the right solution.
+o _c_v_s_t_a_t_i_c accepts regular expressions in nearly all
fields. This can occasionally cause problems if you
unintentionally use a pattern without realizing it is a
regular expression. For example, specifying a filename
of ffffoooooooo....cccc++++++++ usually fails, because ++++ is a special
character in regular expressions.
Workaround: Backslash all regular expression special
characters when not used to specify a wildcard pattern.
For example, the filename mentioned above would be
entered as ffffoooooooo....cccc\\\\++++\\\\++++.
+o The _c_v_s_t_a_t_i_c Variable query, ``Who Sets'' recognizes
only variable assignments that use ``='' to assign
directly to a variable. This query does not recognize
or account for aggregate initialization statements in C
or C++, references in C++, assignments made as a result
of passing or operating on pointers in C, or data,
equivalence, common, or assign statements in Fortran.
Workaround. Use ``Who References'' to see all locations
in which the variable is used and to visually inspect
for assignments.
+o By default, _c_v_s_t_a_t_i_c does not honor _i_f_d_e_f's in source
code. Much of the time, this is desirable behavior.
_c_v_s_t_a_t_i_c allows you to find _a_l_l references that satisfy
a query. However, this may result in an incorrect or
misleading function call tree. Heavily _i_f_d_e_f'd code may
- 22 -
also confuse _c_v_s_t_a_t_i_c, because (in C) _c_v_s_t_a_t_i_c relies
on matching braces to detect the end of functions.
Workaround: Use the ----pppprrrreeeepppprrrroooocccceeeessssssss flag when starting
_c_v_s_t_a_t_i_c. This makes _c_v_s_t_a_t_i_c run much more slowly, but
it honors most _i_f_d_e_fs.
+o _c_v_s_t_a_t_i_c recognizes many common C, C++, and Fortran
language patterns. However, all three languages allow
programmers to write code that is not easily identified
by patterns.
Workaround: If you find that _c_v_s_t_a_t_i_c misses or
misidentifies parts of a program, you can usually
resort to string, regular expression, or symbol queries
to find the information you are looking for.
+o Files containing very long lines are not handled in
scanner mode. If a file contains any line longer than
3000 characters, _c_v_s_t_a_t_i_c's scanner will fail.
Workaround: Use parser mode, or shorten your source
lines.
5.5.4 _K_n_o_w_n _P_r_o_b_l_e_m_s _U_s_i_n_g _c_v_s_t_a_t_i_c _i_n _S_c_a_n_n_e_r _M_o_d_e _w_i_t_h
_C++ _c_v_s_t_a_t_i_c analyzes C++ source code much more accurately
in parser mode than in scanner mode. The following problems
are known to occur in scanner mode. They can be avoided by
following the workaround suggestions, or by using parser
mode.
+o _c_v_s_t_a_t_i_c does not do macro expansion, so classes based
on macros used to simulate C++ parameterized types are
not detected.
+o _c_v_s_t_a_t_i_c does not completely handle function calls made
through function pointers, in C or C++. In C++, this
includes calls to member functions made through object
pointers. For example, consider the following code
segment:
ssssaaaammmmpppplllleeeeffffuuuunnnnccccttttiiiioooonnnn (((())))
{{{{
AAAA ****oooobbbbjjjjeeeecccctttt1111 ==== nnnneeeewwww AAAA(((())));;;;
BBBB ****oooobbbbjjjjeeeecccctttt2222 ==== nnnneeeewwww BBBB(((())));;;;
oooobbbbjjjjeeeecccctttt1111---->>>>ffffuuuunnnncccc(((())));;;;
oooobbbbjjjjeeeecccctttt2222---->>>>ffffuuuunnnncccc(((())));;;;
}}}}
In this example, _c_v_s_t_a_t_i_c correctly reports that
samplefunction() calls func() two times. However, it
- 23 -
cannot determine that these two function calls are
actually made to two different member functions,
implemented by two different classes. Similarly,
_c_v_s_t_a_t_i_c does not know about the _t_h_i_s pointer.
Workaround: Don't try to display full function call
trees for C++. Instead use queries like ``Who Calls
<function>''or ``Who Is Called By <function>'' which
produce meaningful results.
+o _c_v_s_t_a_t_i_c does not understand overloaded functions.
Workaround: Use the text view for all queries involving
overloaded functions.
+o C++ allows extensive use of operator overloading, which
allows you to write code that can obscure what is
really happening in the code. Because _c_v_s_t_a_t_i_c is
designed around a pattern matcher, novel constructs
produced by overloading operators are not normally
detected. Constructs that conform to normal language
conventions should normally be found. For example, if A
and B are objects, and the ``='' operator has been
overloaded to indicate an assignment of the contents of
object B to the contents of object A, _c_v_s_t_a_t_i_c should
be able to handle this situation. However, if some
unusual overloading conventions have been used (say,
using ``[]'' to mean a function call), _c_v_s_t_a_t_i_c does
not show the same results as the C compiler.
Workaround: If you have such code, use string or
regular expression searches, or symbol searches to find
what you are looking for.
+o C++ programs containing templates are not well
understood by scanner mode.
Workaround: Use parser mode.
5.5.5 _K_n_o_w_n__p_r_o_b_l_e_m_s__U_s_i_n_g__c_v_s_t_a_t_i_c__w_i_t_h__F_o_r_t_r_a_n
+o Problem: cvstatic changes case in source files.
Workaround: For best results, ignore case:
Because the Fortran compilers translate Fortran
programs to lower (for Fortran 77) or upper (for
Fortran 90) case when analyzing them, you may have
trouble selecting a symbol name from the Source View
and then using the selection as the target of a query.
Therefore, when using the Static Analyzer on Fortran
- 24 -
sources, it is best to select the Ignore Case option,
either through the General Option menu, or persistently
through the use of the X resource mechanism thus:
cvstatic*ignoreCase: True
+o Problem: Fortran file suffixes are ambiguous.
Workaround: Tell cvstatic what suffixes you use for
which Fortran variant.
Both Fortran 77 and Fortran 90 accept files with the
the suffixes .f and .F. So, there is no obvious way
for the Static Analyzer to tell whether a source file
is Fortran 77 or Fortran 90.
To indicate that you want a particular suffix to
correspond to a particular language, you can set the
suffixSource X resource before running cvstatic. For
example:
*suffixSource: C++.c++ C++.C C++.cxx C++.h C.c
Fortran.f Fortran90.F Fortran90.f90
This line in your .Xdefaults file indicates that you
want files ending .f to be analyzed as Fortran 77
codes, while files ending .F or .f90 are Fortran 90.
You may want to analyze a set of files in which some
files ending .f are Fortran 77 while other files with
the same suffix are Fortran 90. If so, the only way to
distinguish them is for you manually to edit the
cvstatic.fileset file and make sure that each filename
is followed by the correct driver. For example, these
two lines in the fileset file indicate that foo.f is a
Fortran 77 file, while bar.f is Fortran 90:
////uuuussssrrrr////ppppeeeeoooopppplllleeee////yyyyoooouuuu////ffffoooooooo....ffff ffff77777777
////uuuussssrrrr////ppppeeeeoooopppplllleeee////yyyyoooouuuu////bbbbaaaarrrr....ffff ffff99990000
_c_v_s_t_a_t_i_c analyzes Fortran source code much more accurately
in parser mode than in scanner mode. The following problems
are known to occur in scanner mode. They can be avoided by
following the workaround suggestions, or by using parser
mode.
+o _c_v_s_t_a_t_i_c occasionally misses function calls and other
statements that directly follow an _i_f statement on the
same line.
- 25 -
+o _c_v_s_t_a_t_i_c uses a pattern matching approach. This
approach does not allow the tool to detect the
irregular use of spaces within Fortran symbols, even
though these are allowed by the Fortran compiler. For
example, the Fortran compiler accepts the statement:
ssssuuuubbbb rrrroooouuuuttttiiiinnnneeee mmmmyyyy
1111ffffuuuunnnncccc ttttiiiioooonnnn
as if it were written:
ssssuuuubbbbrrrroooouuuuttttiiiinnnneeee mmmmyyyyffffuuuunnnnccccttttiiiioooonnnn
_c_v_s_t_a_t_i_c does not handle such conventions.
Workaround: None in scanner mode. Silicon Graphics
strongly suggests changing such code to use a more
readable coding style.
+o _c_v_s_t_a_t_i_c does not support the use of Fortran keywords
for uses other than their intrinsic function. For
example, _c_v_s_t_a_t_i_c always recognizes word ``if'' as
starting a conditional statement. Programs that use
``if'' as a variable or function name are not analyzed
correctly.
Workaround: None in scanner mode. Silicon Graphics
strongly suggests changing such code to use a more
readable coding style.
+o In some situations, _c_v_s_t_a_t_i_c can mistake references to
arrays as function calls. This is particularly true
when the Fortran code relies on include files to
declare arrays, common blocks, and so on. _c_v_s_t_a_t_i_c does
not analyze header files at the point at which they
occur, but simply adds them to the list of files to be
analyzed. This contributes greatly to the speed of
_c_v_s_t_a_t_i_c, but means that _c_v_s_t_a_t_i_c does not have various
type declarations available to it. Because Fortran
arrays cannot be differentiated from function calls
without a declaration, _c_v_s_t_a_t_i_c identifies arrays not
defined in the file in which they are referenced as
function calls.
Workaround: Use the Results Filter to exclude
``external'' functions. This limits all queries to
those functions actually defined in the fileset.
Excluding external functions hides all array references
erroneously identified as function calls, but also
hides all calls to library functions, intrinsic
functions, or other routines declared outside the
- 26 -
fileset.
5.5.6 _K_n_o_w_n__P_r_o_b_l_e_m_s__U_s_i_n_g__c_v_s_t_a_t_i_c__i_n__P_a_r_s_e_r__M_o_d_e
Sometimes the General query "Where Symbol Used" fails
to report some call sites, if the target of the query
was a function.
WorkAround: Use the Function query "Who Calls" or
"Where Function Used" to get a complete list of places
wehre the target function is called or otherwise used.
+o The query Where Type Used may return duplicate results
in C and C++ programs. For example, asking Where Type
Used Foo will produce two copies of the result showing
the definition of the symbol
FFFFoooooooo ffff;;;;
If one of these locations is shown without a function
field and one is shown with a function, the latter is
correct.
Workaround: If you are explicitly looking for
definitions, use the queries List Data of Type or List
Functions of Type instead. Otherwise, just ignore the
duplications.
+o The query Where Type Used is confusing about pointers
in C and C++.
If you ask Where Type Used about a user-defined type
named Foo, the query will display all uses of Foo,
including uses of types like Foo*, Foo**, Foo[], etc.
But if you ask Where Type Used about a built-in type
like void or char, the query will display only uses of
that exact type.
Workaround: Query explicitly about typenames like
void*, char**, etc, that contain no user-defined
typenames.
+o Queries on "integer" and "real" in fortran don't work.
Fortran reports integer types as having typenames I*4
and I*8, real types with typenames R*4, R*8, complex
types with typenames CM*8 and CM*16, and logical types
as L*4.
Workaround: To inquire about uses and declarations with
these types, enter I*4 (or whatever) into the target
- 27 -
field instead of "integer".
+o Mismatched member function declarations and definitions
are not recognized by _c_v_s_t_a_t_i_c'_s parser. The parser
runs into trouble processing a member function if the
signature of its declaration and definition are not
identical. For example, if the code contains something
like this:
ttttyyyyppppeeeeddddeeeeffff iiiinnnntttt**** iiiinnnnttttppppttttrrrr;;;;
ccccllllaaaassssssss AAAA {{{{
ppppuuuubbbblllliiiicccc::::
AAAA ((((iiiinnnntttt **** iiii))));;;;
}}}};;;;
AAAA::::::::AAAA ((((iiiinnnnttttppppttttrrrr iiii)))) {{{{
}}}}
the parser will print the error message "no record for
method A::A?" and terminate processing of the file.
Workaround: analyze code like this in scanner mode, or
change the type signatures so that the definition and
declaration match.
+o _c_v_s_t_a_t_i_c's parser mode is better at building a new
database than at modifying an existing one. If you
build a parser-mode database and then change a file and
reparse it, the database will grow each time you rescan
the file. Not all space is reclaimed. Additional arcs
may appear in the Call Tree view representing defunct
call site information.
Workaround: After a few files are modified and re-
analyzed, it is best to use Force Scan to rebuild the
entire parser-mode database. For a large code base that
is slow to parse, you can use the -batch flag to
rebuild the database overnight.
+o Functions generated by templates are recognized and
displayed by _c_v_s_t_a_t_i_c, but it treats them as external
functions: functions that are declared or used within
the fileset but are not defined there. Consequently,
they do not appear in the results of the ``Query List
All Functions''.
Workaround: Use specific queries about these functions,
like ``Where Function Called'', or add them manually to
Call Tree graphs.
- 28 -
+o The function "main" appears in the list of Functions
Not Called, if it is not called explicitly from the
source code. ("main" is rarely called explicitly.)
Workaround: You can add the function "main" manually to
any graphical display of functions.
+o Graphical display of a single member function called
through derived classes is incomplete. If a C++ member
function FFFFoooooooo::::::::FFFFuuuunnnncccc is called through classes derived
from the ccccllllaaaassssssss FFFFoooooooo, each derived function FFFFuuuunnnncccc will
appear as a separate function in the Text View list of
functions. However, only one node will appear for FFFFuuuunnnncccc
in the Call Tree View.
Workaround: To see the full list of definitions and
calls of FFFFuuuunnnncccc, use Text Mode. If you double click on
the definition of one of the derived FFFFuuuunnnnccccs, you will
navigate either to the definition of the function (if
you click on the version in FFFFoooooooo), or to the definition
of the derived class through which FFFFuuuunnnncccc was called.
+o If you are analyzing C++ code in which multiple non-
member functions have the same name, _c_v_s_t_a_t_i_c will
think they are all the same function with one
definition and several declarations.
Workaround: You can get to the definitions by using the
``Where Defined'' and ``Where Declared'' queries on
functions.
+o When you first bring up _c_v_s_t_a_t_i_c, if you switch the
view from Text View to a graph view before building the
parser database and doing your first query, the graph
may incorrectly display as empty.
Workaround: Stay in Text View to perform your first
query, and then switch to whichever graph view you
wish. Or, if you have already brought up _c_v_s_t_a_t_i_c in a
graph view and built the database, hit ``Rescan'' in
the Admin menu, and then redo your query.
5.6 _W_o_r_k_S_h_o_p__C_+_+__B_r_o_w_s_e_r
+o The _C++ _B_r_o_w_s_e_r currently works only on files in the
parser fileset. So if you have a fileset which has
only files in the scanner fileset, the browser will not
work. To generate the database, you have to put files
in the parser fileset and issue a rebuild in _c_v_s_t_a_t_i_c.
Once the database is created you can use Browser to
- 29 -
examine the C++ classes.
+o When using the C++ Browser, if you make changes to the
code in the files that are present in the fileset, the
changes will not be reflected in the information
presented by the C++ Browser until you issue a Rescan
command in _c_v_s_t_a_t_i_c, as follows:
* Make your changes.
* Exit the C++ Browser (but not cvstatic).
* Issue a FFFFoooorrrrcccceeee SSSSccccaaaannnn from the cvstatic AAAAddddmmmmiiiinnnn menu.
* Restart the browser by selecting AAAAddddmmmmiiiinnnn/CCCC++++++++ BBBBrrrroooowwwwsssseeeerrrr
menu in cvstatic.
Incident 186990.
+o Duplicate class definitions encountered in your files
in the parser fileset will end up as a single class
with accumulating members from both the definitions.
This happens when the file defining the class is
included from two different paths or there are two
genuine class definitions for the same class name in
your fileset.
Incident 206922.
+o If you use typedefs, and use it to give alternate names
to classes (as in _t_y_p_e_d_e_f _c_l_a_s_s _A _B;) - you may that
the Build Window shows some warnings about not finding
the class B and that the information collected about
the usage of class A will be missing many of the
references through its typedef B.
This kind of typedef is more commonly found in template
code. There is no good workaround currently, other than
not using the typedef in question.
Incident 217830.
+o If you use typedefs, and use it inconsistently in
declaring and defining class members (as in the
following example), you will find that information
regarding those members is either missing or faulty.
The workaround is to use the same prototype at the
point of definition as at the point of declaration.
ttttyyyyppppeeeeddddeeeeffff iiiinnnntttt IIIINNNNTTTT;;;;
ccccllllaaaassssssss AAAA {{{{
- 30 -
vvvvooooiiiidddd ffffoooooooo ((((IIIINNNNTTTT))));;;;
}}}};;;;
vvvvooooiiiidddd AAAA::::::::ffffoooooooo ((((iiiinnnntttt vvvvaaaallll)))) ............ //////// ggggeeeettttssss wwwwaaaarrrrnnnniiiinnnngggg,,,, aaaannnndddd iiiissss mmmmiiiissssssssiiiinnnngggg
//////// ffffrrrroooommmm ssssttttaaaattttiiiicccc aaaannnnaaaallllyyyyssssiiiissss iiiinnnnffffoooo....
Incident 184455.
+o Usage information for template classes is managed only
on a per-instantiation basis. If you use templates in
your code, then each instantiation, and the template
itself, will show up as classes in the C++ Browser.
For instance, if you have a template class Foo<T>, then
there will be a class called FOO<T> and classes FOO<A>,
FOO<B> etc., for the template definition prototype of
FOO and its instantiations with A, B, etc.,
respectively. And the usage information on FOO<T>
currently shown is not the amalgamation of usage
information on its instantiations FOO<A>, FOO<B>, etc.
+o Be careful about overwriting man pages which are
generated using the automatic class man page generation
facility.
When you generate a manpage for a class, through the
C++ browser, you get a skeleton, in which you have to
fill in all the descriptions. Please remember that if
you change the class and generate a new man page for
that class again, your changes to the file will be lost
if you ignore the man page overwrite warning dialog.
To avoid losing your changes to a manpage file
generated by C++ Browser do the following:
* Move the existing manpage out of the way to some
other file.
* Generate the new (skeleton) man page.
* Merge the changes from the saved file to the new
man page generated by the C++ Browser.
+o When you use an application which allocates lot of
colors in the default color map and then use cvstatic
or C++ browser to bring up graphs, you might get all
black nodes with un-readable text. The only known
workaround to this problem is to kill the X server and
login again. Be sure that you bring up cvstatic before
you bring up the offending application. This problem
has been seen with viewing books which have full color
- 31 -
pictures.
5.7 _W_o_r_k_S_h_o_p__P_e_r_f_o_r_m_a_n_c_e__A_n_a_l_y_z_e_r
+o Total-time and bottleneck experiments will overcount
inclusive time for recursive functions (Incident
#438591)
+o The Main View has a notion of a default trap that is a
stop trap if data collection has not been enabled in
the Performance Panel (where ``enabled'' means after
_A_c_c_e_p_t or _O_K was clicked), and a sample trap if it has
been enabled. This setting is independent of the
default trap set in the Trap Manager. Clicking in the
margin of the MainView source window sets or clears the
MainView default trap, and does not affect a trap of
the other type.
+o The WorkShop Performance Analyzer can record
experiments on MP FORTRAN programs, but there are a
number of anomalies in the displayed data that require
explanation. For all FORTRAN MP compilations, parallel
loops within the program are represented as subroutines
with names relating to the source routine in which they
are embedded. The naming conventions for these
subroutines are different for o32-bit, N32, and 64-bit
compilations. In the linpack benchmark, most of the
time spent is in the source routine _D_A_X_P_Y, which can be
parallelized. The MP loop-body routines are invoked
indirectly from the original function, and will show up
as directly calls from a routine name __mp_parallel_do.
When compiled with the 7.2 or later compilers, in
either 64-bits, or n32, the MP loop-body routine is
named "__mpdo_daxpy_1", and the function is named
"daxpy_". However, there is a test in the compiled
loop to determine if the work to be done is sufficient
to be worth running in parallel. That means if the
test succeeds, time will be shown in the routine
__mpdo_daxpy_1, while if the test fails, the time will
be recorded in the routine daxpy_.
In an o32-bit version, the _D_A_X_P_Y routine is named
"daxpy_", and the MP loop body routine
"_daxpy_519_aaab_".
In all three cases, for an ideal time experiment on a
uniprocessor -_g run,the inclusive and exclusive
function level times are correct. The source
annotations, however, behave differently in most cases.
- 32 -
With the 7.2 or 6.x compilers, source annotations for
the exclusive time are correctly shown for each line,
but the inclusive time for the first line of the loop
(_d_o statement) includes the time spent in the loop
body. This same time appears on the lines comprising
the loop's body, in effect, representing a double-
counting. When used in conjunction with WorkShop Pro
MPF's Parallel Analyzer View, the loop performance data
will incorrectly also reflect the double counting, and
the time will not be always shown as a percentage:
whenever it would exceed 100%, it is shown as <_n/_a>.
The numerical time value shown reflects the double
counting.
In 32-bit source annotations, the exclusive time is
incorrectly shown for the line comprising the loop's
body, as the line-level data for the loop-body routine
("_daxpy_519_aaab_") does not refer to proper lines.
If the program was compiled with the -_m_p__k_e_e_p flag, the
line-level data should refer to the temporary files
that are saved from the compilation, but the temporary
files do not contain that information, so no source or
disassembly data can be shown. The disassembly data
for the main routine does not show the times for the
loop-body.
If the 32-bit program was compiled without -_m_p__k_e_e_p,
the line-level data for the loop-body routine is
incorrect, with most lines referred to line 0 of the
file, and the rest to other lines at seemingly random
places in the file. Consequently, spurious annotations
will appear on these other lines. Disassembly
correctly shows the instructions, and their data, but
the line numbers shown are wrong. MPF's Parallel
Analyzer correctly shows the loop data in most cases,
but the same incorrect line numbers can cause data
relating to one loop to show up in other parts of the
program. This reflects what is essentially the same
double-counting problem as seen in 64-bits, but the
extra counts go to other places in the file, rather
than the first line of the loop.
NNNNOOOOTTTTEEEE:::: We recommend against using the -_m_p__k_e_e_p flag.
+o For MP experiments run under the debugger, stopping one
thread can cause the notion of time in other threads to
get confused. It is not recommended.
+o The inclusive data shown in _c_v_p_e_r_f represents the
instruction counts and/or PC sampling data summed over
the routine and those routines that it calls. The
- 33 -
computations are based on a heuristic that assumes that
all calls from all callers are equivalent. For
programs where this heuristic is not applicable, for
example, where one call to a matrix-multiply routine is
for matrices of order four, while a second call is for
matrices of order 100, the cumulative data may be
misleading.
+o Line-level data assigns a value to a line equal to the
highest value for any instructions attributed to that
line. It can be confusing, because compiler
optimizations often rearrange the code in ways that is
non-obvious. Looking at a disassembly view of the data
can help.
+o Line-level data from assembler routines can be
misleading. The symbol table often has instructions
attributed to the wrong source line.
+o _c_v_p_e_r_f filters out nodes and arcs that were not
executed during the current caliper setting. This
feature can lead to confusing displays, where nodes
that are known to be in the program do not appear.
Workaround: The Preferences menu can be used to disable
the filtering.
+o _c_v_p_e_r_f does not support live performance experiments.
That is, you should not bring up _c_v_p_e_r_f until the
experiment is over. If you do, it will not update as
more data is recorded.
+o Performance experiments on multi-process applications
can occasionally be unreliable if sample events are
quickly preceded by process creation, or succeeded by
process termination.
+o Heap View scrolls poorly and blocks flash on large
experiments. Its functionality has been mostly
subsumed by Leak View, Malloc View, and Malloc Error
View. (Incident# 571496)
+o Source or disassembly cycle annotations may overflow
for high counts in pixie mode. (Incident# 244871)
+o Cvperf can not generate source annotations for corded
binaries. (Incident# 597302)
+o Cvperf option for noise-filter w/"important children"
command may not work. (Incident# 503751)
- 34 -
+o Cvperf's call graph will be incomplete for the Fortran
symbol "MAIN__" and the program name if produced by 7.2
or later compilers. (Incident# 503928)
+o Experiment file aggregation by cvperf is limited to
files from a single run. Aggregation is also limited
to experiment files that have the same number of
caliper points. (Incident #618507)
+o When running performance experiments on MPI
applications, a master experiment file will get
generated on each host in addition to the experiment
files for the MPI slaves. The master experiment file
contains no application-related performance data.
+o Call stacks with the "cc" marching order can not be
generated for trap-based caliper points. (Incident
#618550)
+o Performance data collection doesn't imply attachment to
the debugger anymore. If that's required (for trap-
based caliper points for example), then it can be set
to do so via the configuration option of the Perf menu.
5.8 _W_o_r_k_S_h_o_p__T_e_s_t_e_r
5.8.1 _W_o_r_k_S_h_o_p__T_e_s_t_e_r__L_i_m_i_t_a_t_i_o_n_s
+o Instrumented programs can increase in size by a factor
of 2X to 5X. However, DSO caching and sharing
alleviates this problem greatly.
+o Block and branch coverage are at the assembly language
level. They can provide useful metrics and do map back
to the source lines. Note that several assembly branch
instructions may map back to the same source line. To
see the C, C++, and Fortran source level blocks and
branches, use _c_v_c_o_v _l_s_s_o_u_r_c_e.
+o Compilation with the debug flag -_g builds assembly
language branches and blocks that can never be
executed. This adversely affects overall coverage. By
compiling with "O1" (the default), some of the unused
assembly branches and blocks are not built. This gives
a more accurate block and branch coverage metric.
Function and arc coverage are unaffected by compile
flags.
+o C++ in-line functions are not counted as functions
unless they are out-of-lined by the compiler.
- 35 -
+o By default, arguments of functions are not displayed in
query results. This can be confusing for C++
overloaded functions because there is no way to
distinguish between them. To work around this problem,
use the -_a_r_g option to show full function signatures.
+o The default size of the SourceView annotation canvas
may not be large enough to hold very large counts. The
resource name for setting canvas width for SourceView
is "canvasWidth". The default value is 60. The user
can modify this width by modifying the following
resource found in the Cvxcov app-defaults file,
"Cvxcov*test*testData*canvasWidth".
+o _T_e_s_t_e_r currently uses object level instrumentation.
This has several advantages:
((((1111)))) CCCCoooovvvveeeerrrraaaaggggeeee ddddaaaattttaaaa ccccaaaannnn bbbbeeee oooobbbbttttaaaaiiiinnnneeeedddd wwwwiiiitttthhhhoooouuuutttt aaaacccccccceeeessssssss ttttoooo tttthhhheeee
ssssoooouuuurrrrcccceeee ccccooooddddeeee....
((((2222)))) CCCCoooovvvveeeerrrraaaaggggeeee ddddaaaattttaaaa ccccaaaannnn bbbbeeee oooobbbbttttaaaaiiiinnnneeeedddd wwwwiiiitttthhhhoooouuuutttt rrrreeeeccccoooommmmppppiiiillllaaaattttiiiioooonnnn////rrrreeeebbbbuuuuiiiilllldddd....
((((3333)))) TTTThhhhiiiissss ssssuuuuppppppppoooorrrrttttssss CCCC,,,, CCCC++++++++,,,, aaaannnndddd FFFFoooorrrrttttrrrraaaannnn wwwwiiiitttthhhhoooouuuutttt ssssppppeeeecccciiiiaaaallll
llllaaaannnngggguuuuaaaaggggeeee ssssuuuuppppppppoooorrrrtttt ffffrrrroooommmm tttthhhheeee ccccoooommmmppppiiiilllleeeerrrrssss....
This has several disadvantages:
((((1111)))) BBBBlllloooocccckkkk aaaannnndddd bbbbrrrraaaannnncccchhhh ccccoooouuuunnnnttttssss aaaarrrreeee aaaatttt tttthhhheeee aaaasssssssseeeemmmmbbbbllllyyyy llllaaaannnngggguuuuaaaaggggeeee lllleeeevvvveeeellll....
((((2222)))) MMMMoooorrrreeee ddddeeeettttaaaaiiiilllleeeedddd ccccoooovvvveeeerrrraaaaggggeeee rrrreeeeqqqquuuuiiiirrrreeeessss kkkknnnnoooowwwwlllleeeeddddggggeeee ooooffff tttthhhheeee
llllaaaannnngggguuuuaaaaggggeeee sssseeeemmmmaaaannnnttttiiiiccccssss.... FFFFoooorrrr eeeexxxxaaaammmmpppplllleeee,,,, hhhhaaaassss eeeevvvveeeerrrryyyy ppppoooossssssssiiiibbbblllleeee ccccaaaasssseeee
iiiinnnn aaaa mmmmuuuullllttttiiiipppplllleeee ccccoooonnnnddddiiiittttiiiioooonnnnaaaallll ffffiiiirrrreeeedddd dddduuuurrrriiiinnnngggg tttteeeessssttttiiiinnnngggg....
+o _W_e_a_k _e_x_t_e_r_n_a_l_s refer to an aliasing facility used by
the compilation environment. For example, while user
programs may call the function "read", the actual
function name in the C library that implements "read"
is "_read". In this case, "read" is a weak external for
"_read". If the user CONSTRAINS coverage on either
name, _T_e_s_t_e_r will report the results correctly.
However, _T_e_s_t_e_r will choose the name used to implement
the function, in this case "_read".
+o -_f_u_n_c__p_a_t_t_e_r_n is a function pattern used in the
following _c_v_c_o_v subcommands: _l_s_b_l_o_c_k, _l_s_b_r_a_n_c_h, _l_s_f_u_n,
_l_s_t_r_a_c_e. Currently, only the following "patterns" are
matched.
""""DDDDSSSSOOOO::::****"""" -------- aaaallllllll ffffuuuunnnnccccttttiiiioooonnnnssss iiiinnnn aaaa DDDDSSSSOOOO
DDDDSSSSOOOO::::ffffuuuunnnnccccttttiiiioooonnnn____nnnnaaaammmmeeee -------- ssssppppeeeecccciiiiffffiiiicccc ffffuuuunnnnccccttttiiiioooonnnn iiiinnnn aaaa DDDDSSSSOOOO
ffffuuuunnnnccccttttiiiioooonnnn____nnnnaaaammmmeeee -------- ffffuuuunnnnccccttttiiiioooonnnn____nnnnaaaammmmeeee iiiinnnn mmmmaaaaiiiinnnn pppprrrrooooggggrrrraaaammmm aaaannnndddd ddddssssoooo''''ssss
<<<< ooooppppttttiiiioooonnnn nnnnooootttt uuuusssseeeedddd >>>> -------- aaaallllllll ffffuuuunnnnccccttttiiiioooonnnnssss aaaarrrreeee iiiinnnncccclllluuuuddddeeeedddd iiiinnnn qqqquuuueeeerrrryyyy
- 36 -
+o Sharing of the WorkShop Performance Analyzer
performance experiment data is supported in _c_v_c_o_v but
not in _c_v_x_c_o_v of this release.
+o Output of query results to a printer is not supported
in this release. As a workaround, the user can save
query results to a file, and then send that file to a
printer.
+o Experiment data for test sets/test groups cannot be
moved/copied (mv, cp) without invalidating the data.
Leaf tests can be moved/copied.
+o Both the _l_s_t_r_a_c_e feature (argument tracing) and the
_l_s_s_o_u_r_c_e feature (mapping block counts to actual
source) require the code to be compiled with -_g. A
notable exception to this is return value tracing which
can trace the return value on functions that are not
compiled with -_g (e.g., _l_i_b_c functions).
+o _c_v_c_o_v requires that all instrumentation be performed
before the experiment is run. This includes
instrumentation for programs that are forked/exec'ed or
sproc'ed. _c_v_m_o_n is the program used by _c_v_c_o_v to
monitor the experiment. If _c_v_m_o_n encounters child
processes, and the coverage experiment includes any
executables other than the main program, then _c_v_m_o_n
will instrument the executables for the child processes
"on the fly". _c_v_c_o_v will not process coverage for
these "on the fly" instrumented executables, because
_c_v_m_o_n has not used the correct coverage instrumentation
criteria. This can cause performance and space
overhead.
+o IRIX 5.1 and later binaries are supported (no support
for IRIX 4.0.X binaries) including shared and
nonshared.
+o Instrumentation criteria ccccoooouuuunnnnttttssss must at least include
----bbbbbbbbccccoooouuuunnnntttt. For example, if user want to test function
pointers the instrumentation file must contain the
following line,
CCCCOOOOUUUUNNNNTTTTSSSS ----bbbbbbbbccccoooouuuunnnnttttssss ----ffffppppccccoooouuuunnnnttttssss
+o The current model for running instrumented programs
requires that a separate process (_c_v_m_o_n) monitor the
programs that are undergoing coverage analysis. This
requires existing test scripts to be modified in the
following manner:
- 37 -
oooolllldddd ssssccccrrrriiiipppptttt::::
#### pppprrrrooooggggrrrraaaammmm aaaarrrrgggg1111 aaaarrrrgggg2222
nnnneeeewwww ssssccccrrrriiiipppptttt::::
#### ccccvvvvccccoooovvvv mmmmkkkktttteeeesssstttt ----ccccmmmmdddd """"pppprrrrooooggggrrrraaaammmm aaaarrrrgggg1111 aaaarrrrgggg2222"""" ----tttteeeessssttttnnnnaaaammmmeeee tttteeeesssstttt
#### ccccvvvvccccoooovvvv rrrruuuunnnntttteeeesssstttt tttteeeesssstttt
+o There is potentially a large amount of data that can be
captured when running multiple tests for large
programs. There are several options to the _r_u_n_t_e_s_t
command that help manage this data.
The -_n_o_a_r_c option is used to eliminate the capture of
arc data in the experiment result (e.g., arc AB is
equivalent to function A calls function B from line X).
This significantly reduces the amount of overall count
information for the test coverage result.
The -_r_m_s_u_b option is used to retain the overall results
for the top level test set or test group, not for the
individual subtests. There are several interactions of
the -_r_m_s_u_b and -_s_u_m options worth noting. If the
-_r_m_s_u_b option is used, a subsequent "runtest" using the
-_s_u_m option will not accumulate the counts data for
these two runs. In this case only the second run will
be in the top level test set/test group. The -_s_u_m
option will sum up data only according to the count
data that is in all the subtests currently and does not
use the information in the top level test set or test
group. When using the -_s_u_m and -_r_m_s_u_b options
together, the count data will be accumulated and the
subtest data will be deleted.
The -_c_o_m_p_r_e_s_s option is used to compress experiment
database using standard utility _c_o_m_p_r_e_s_s.
The -_b_i_t_c_o_u_n_t option is used to convert experiment
database to 1-bit-per-count format in recording
experiment so that it will save disk space up to 32
times. However, count number for basic blocks and
branch coverage information will be lost.
+o Source highlighting for statement that cover multiple
lines only highlights the last line. This is due to a
limitation in symbol table data generated by the
compiler. For example, in the following source
statement only the second line will be highlighted:
pppprrrriiiinnnnttttffff((((""""TTTThhhhiiiissss iiiissss aaaa tttteeeesssstttt ffffoooorrrr %%%%ssss aaaatttt %%%%dddd"""",,,,
0000 tttteeeessssttttnnnnaaaammmmeeee,,,,wwwwhhhhiiiicccchhhhDDDDrrrriiiivvvveeee))));;;;
- 38 -
+o If the DSO cache directory has been removed, all the
existing experiments may be invalid and _T_e_s_t_e_r may not
work.
5.8.2 _W_o_r_k_S_h_o_p__T_e_s_t_e_r__B_u_g_s
+o Programs that use _a_r_g_v[_0] to build hardcoded filenames
get confused by the renamed instrumented program (e.g.,
<program> becomes <program_Instr>).
5.9 _W_o_r_k_S_h_o_p__E_n_v_i_r_o_n_m_e_n_t
+o If the colors of your WorkShop windows look too dark to
read or conversely if they look completely washed out,
there may be a discrepancy between the gamma value you
are using and the value your X server is using. The
default value of gamma on installation is 1.7 but users
running X programs may prefer a value of 1.0.
Workaround: If you change your gamma value, by running
the _g_a_m_m_a program (installed with _e_o_e_2._s_w._g_l_t_o_o_l_s),
restart your X server.
+o When starting up WorkShop, if you see the messages
////uuuussssrrrr////ssssbbbbiiiinnnn////ttttttttsssseeeessssssssiiiioooonnnn:::: CCCCaaaannnn''''tttt iiiinnnniiiitttt ttttyyyyppppeeee ddddaaaattttaaaabbbbaaaasssseeee....
////uuuussssrrrr////ssssbbbbiiiinnnn////ttttttttsssseeeessssssssiiiioooonnnn:::: eeeexxxxiiiittttiiiinnnngggg
WWWWaaaarrrrnnnniiiinnnngggg:::: ttttttttsssseeeessssssssiiiioooonnnn:::: ssssiiiigggg____hhhhaaaannnnddddlllleeeerrrr:::: NNNNoooo cccchhhhiiiilllldddd pppprrrroooocccceeeesssssssseeeessss
////uuuussssrrrr////ssssbbbbiiiinnnn////ttttttttsssseeeessssssssiiiioooonnnn:::: CCCCaaaannnn''''tttt iiiinnnniiiitttt sssseeeerrrrvvvveeeerrrr....
ttttttttsssseeeessssssssiiiioooonnnn:::: CCCCaaaannnn''''tttt iiiinnnniiiitttt ttttyyyyppppeeee ddddaaaattttaaaabbbbaaaasssseeee....
ttttttttsssseeeessssssssiiiioooonnnn:::: eeeexxxxiiiittttiiiinnnngggg
WWWWaaaarrrrnnnniiiinnnngggg:::: ttttttttsssseeeessssssssiiiioooonnnn:::: ssssiiiigggg____hhhhaaaannnnddddlllleeeerrrr:::: NNNNoooo cccchhhhiiiilllldddd pppprrrroooocccceeeesssssssseeeessss
ttttttttsssseeeessssssssiiiioooonnnn:::: CCCCaaaannnn''''tttt iiiinnnniiiitttt sssseeeerrrrvvvveeeerrrr....
TTTTttttuuuuttttiiiillll:::: CCCCaaaannnnnnnnooootttt ooooppppeeeennnn oooouuuurrrr TTTToooooooollllTTTTaaaallllkkkk pppprrrroooocccceeeessssssss iiiidddd
ttttttttuuuuttttiiiillll:::: CCCCoooouuuullllddddnnnn''''tttt ccccoooonnnnnnnneeeecccctttt ttttoooo ttttttttsssseeeessssssssiiiioooonnnn sssseeeerrrrvvvviiiicccceeee((((ssss))))....
check if you have the _C_E_P_A_T_H environment variable set.
ToolTalk will use the _C_E_P_A_T_H variable for its
definition of where the types database are located.
WorkShop expects to find them in the default system
database, /_e_t_c/_t_t/_t_y_p_e_s._x_d_r. Unsetting this environment
variable will fix the startup problem.
+o When starting up WorkShop, you may occassionally see
the message
////uuuussssrrrr////ssssbbbbiiiinnnn////ttttttttsssseeeessssssssiiiioooonnnn:::: WWWWaaaarrrrnnnniiiinnnngggg:::: ccccoooouuuullllddddnnnn''''tttt aaaaccccqqqquuuuiiiirrrreeee XXXX sssseeeelllleeeeccccttttiiiioooonnnn
ToolTalk displays this message when its internal state
notes that someone else (i.e. another _t_t_s_e_s_s_i_o_n) has
- 39 -
already owned the X selection that it is trying to
aquire. This message is harmless and can be ignored.
+o The network license mechanism used by WorkShop performs
periodic checks to ensure that a license is available.
Once obtained, a license is valid for 20 minutes. The
license is validated every 10 minutes, and renewed for
an additional 20 minutes if all is well. This process
requires that WorkShop be actively running to be able
to perform these checks. If the tool is unable to check
the license server for 20 minutes, the license is lost,
and the tool must be restarted to get a new license.
Therefore, suspending a WorkShop process (using <Ctrl-
Z>, for example) for more than a few minutes loses the
tool's license.
+o The WorkShop environment works with one configuration
management system at a time. This affects all users
running WorkShop on that machine.
+o The default for string data is to display it as a hex
address. If you prefer the behavior of showing a
string for _c_h_a_r *, you can set ****aaaauuuuttttooooSSSSttttrrrriiiinnnnggggFFFFoooorrrrmmmmaaaatttt to
TTTTrrrruuuueeee in your ._X_d_e_f_a_u_l_t_s. This will automatically
change the result format from the default to string for
_c_h_a_r * and _c_h_a_r <_a_r_r_a_y> expressions in the
ExpressionView, VarBrowser, and DataBrowser.